Net Solutions
Introduction
The D3Events component provides secure interoperable access to security salient meta data
Design
A D3Events server is the entity capable of generating D3Events events
A D3Events client, is one or more applications that are receiving D3Events events.
The D3Events has been design to support push and pull interfaces.
The pull interfaces is where the D3Events Client discovers the D3Events Server and subscribes to events
The push interface is where the D3Events Server discovers the D3Events Client and pushes an event stream.
Local and remote
The D3Events interface has been designed to support local and remote access.
In many examples the D3 Agent will be collocated with the D3Events Server; both will be on the gateway.
However, the design does not enforce this constraint. The API can be remotely invoked. This means the D3Events can conceivably be used in the following scenarios.
- D3Events Server is on the local intranet - but the D3 Agent is sitting in the cloud.
- D3 Agent aggregates D3Events server information from multiple gateway entities, whether these are network extenders or gateway/routers sat on different physical instances
- D3 Agent aggregates D3Events server from multiple protocol bridges. A protocol bridge is the generic term for any entity on the internal network capable of translating from one protocol to another (e.g. Zigbee, Zwave, BT, Lora)
API and encoding
Due to the volume of traffic that a network monitoring entity can create it is important that the transport and encoding used to transmit the information be as efficient as possible. For that reason gRCP has been selected as the transport protocol, and protobuf is therefore used to encode the individual messages.
Should a REST interface be required this can be provided using a rRPC HTTP proxy such as envoy.
Discovery and security
The D3Events specification is silent on the method by which a D3Events client discovers a D3Events server. This is left as an implementation detail.
D3Events is built on top of gRPC and therefore transported over HTTP/2 . In most situations this should be encrypted, and as per HTTP2 standard this must used TLS 1.2 or higher.
It is recommended that the client and server authenticate using their signing keys. This means that any message sent over the D3Events interface can be deems "signed"
Event schemas
The D3Events API is capable of transporting any message.
The protobuf messages defined in this version of the D3Events spec, should be interpreted as a minimal least common denominator profile.
These many be extended with other profiles later
Implementers are free to add their own proprietary extension.
Relationship to D3 claims
Each D3Events event received by the D3Events client should have equivalent status to a D3 claim, where the D3Events event is the payload, and is signed by the D3Events server.
The events not individually signed but are streamed within an authenticated an encrypted stream as an optimisation.
Example code
Alex is this text still correct
::::
In the D3Events protocol definition the client, which acts as the data generator calls the Publish$nameStream, where $name is the protocol name.
Each gRPC function contains the parameters bytes ether_id, which uniquely identifies the Ethernet packet and the corresponding protocol data fields.
The server replies with status parameter from PublishResponse.
The requests is streamed, which allows the server to start, stop, unsubscribe, etc., from the publisher stream.
D3Events Event Implementation
This schema represent the post processed meta data created from live network monitoring (PCAP)
We are attempting to identify an optimal schema that can be used for operational network enforcement and anomaly detection
The data must be sufficiently rich to implement the enforcement and anomaly detection
But the data must be sufficiently streamlined to be operationally viable
We expect the profile of the events to evolve as we test the efficacy of the transported code in the context of anomaly detection analytics.
Example
See exemplar